This rule requires that any declaration of an object type specify the exact properties that make up the object.

Do we actually validate this?

To clarify, I don't necessarily see it as a blocker, since this effort can be future-compatible to some future enhancement to implement the validation.

Size Change: 0 B

Total Size: 841 kB

_{compressed-size-action}

It's a common point of strain in the implementation of these custom rules, but: Are "blocks" a thing that @wordpress/eslint-plugin (an otherwise generic set of ESLint lint configurations and rules) should be aware of / concerned with?

The answer may very well be "Yes". Some of the existing rules could similarly qualify as being pretty WordPress-specific (i18n rules, for example).

@mcsf I was thinking about this really but I don't know why attributes schema model wasn't structured like JSON schema model from first. It looks like custom schema built for Gutenberg rather than JSON schema.
I saw your example on the merge request:

( {
    "name": "my/gallery",
    "category": "widgets",
    "attributes": {
        "images": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "id": {
                        "type": "number"
                    },
                    "width": {
                        "type": "number"
                    }
                },
               "required": ['id', 'width']
            }
        }
    }
} )

But what if I would like to have the images attribute itself required
I was thinking it would be more appropriate to have the registration api like the following:

({
  name: "my/gallery",
  category: "widgets",
  attributesSchema: {
    properties: {
      images: {
        type: "array",
        items: {
          type: "object",
          properties: {
            id: {
              type: "number"
            },
            width: {
              type: "number"
            }
          },
          required: [ "id", "width" ]
        }
      }
    },
    required: [ "image" ],
    additionalProperties: false
  },
  // For having default attributes
  initialAttributes: {
  }
});

and in registration, we force {type: "object"} to be merged with attributesSchema because of course attributes must be an object
I am just sharing my thoughts to have like a standard api for this schema model like the Rest api standards.

However, I believe my suggestion is so late because how the things got structured already, there won't be such a flexibility.
Like for example:

{
    url: {
        type: 'string',
        source: 'attribute',
        selector: 'img',
        attribute: 'src',
    }
}

Extracting the src attribute from an img found in the block’s markup.
This isn't like JSON schema by any way and to re-structure the attributes schema to be exactly like JSON schema, this might be impossible at this phase.
But please don't get me wrong, I agree with this merge request.

This rule requires that any declaration of an object type specify the exact properties that make up the object.

Do we actually validate this?

As discussed: on the client we don't, though on the server the WP API does validate. Whatever we build in the future to actually use validation, I personally think there is already a benefit in requiring the developer to be explicit in data needs.

It's a common point of strain in the implementation of these custom rules, but: Are "blocks" a thing that @wordpress/eslint-plugin (an otherwise generic set of ESLint lint configurations and rules) should be aware of / concerned with?

I battled with this myself, and I think you can tell in the fact that I zigzag between mentions of "JSON schema" (dubious) and "block attributes" (also dubious because the rule obviously doesn't actually analyze the declarations).

Keeping small in scope and generic enough to be compatible with the WP API can help justify that it remain a part of a WP set of rules, as you suggest:

The answer may very well be "Yes". Some of the existing rules could similarly qualify as being pretty WordPress-specific (i18n rules, for example).

Hi, @muhammedmagdi —

I was thinking about this really but I don't know why attributes schema model wasn't structured like JSON schema model from first. It looks like custom schema built for Gutenberg rather than JSON schema.

Indeed, though the attribute model in Gutenberg was influenced by JSON Schema, it was shaped by more pressing concerns around attribute sourcing, concerns that JSON Schema might not have responded to. Roughly, the only things that mattered for an attribute would be its base type and, if any, its default value; internally, the only validation really happening was the casting of values to the base type.

Meanwhile, being able to declare complex sourcing of attributes was a much more powerful feature for Gutenberg. It allowed attributes to be sourced from the actual block markup, thereby avoiding the need to duplicate data between the data encoded in the block boundary and the markup. It also allowed the use of completely different sources: an attribute may live in a post's metadata, for instance.

But what if I would like to have the images attribute itself required

Attributes themselves shouldn't need the required property because this doesn't address an actual issue in Gutenberg: attributes either have a default value, in which case the need for an value is always fulfilled, or they should handle empty states manually — which is already necessarily mediated by a block's edit method.

This doesn't preclude some sort of required support for attributes, but I don't know what that would look like, nor what real problems it would solve.

However, I believe my suggestion is so late because how the things got structured already, there won't be such a flexibility.

Correct, the current schema is here to stay, even if we allow optional enhancements in the future.

JSON Schema is a very expressive system which, if fully taken advantage of, would likely be "too much" for Gutenberg. What prompted this pull request was the observation that, over time, blocks that grow in complexity tend to escape Gutenberg's attribute validation system by introducing "wildcard" attributes that can contain anything. We can mitigate this by requiring arrays to specify items: { type: 'foo' } and objects to specify properties: { ... }.

In the same vein, it would be great to add a similar check for ensuring that array types have a specified items.

In the same vein, it would be great to add a similar check for ensuring that array types have a specified items.

@TimothyBJacobs: if agree with the general direction, then yes, arrays should be addressed too. What do you think about #21687 (comment) and #21687 (comment)?

I personally think it's a worthwhile change in itself: it both guides developers and requires something of them, even if the editor doesn't validate the data.

What’s the status of this PR? 😃

What’s the status of this PR? 😃

It's been a while. Personally, do you think it has value? This was a nice thing to try out, but I don't feel strongly about getting it in. :)

I did another check for this PR and I found one fundamental issue with this proposal. While I'm personally very much in favor of having this type of validation added, it wouldn't be useful in the actual form simply because we have all block definitions in block.json file now. Do you think we could include it in the application logic instead? Maybe something enabled only in the development mode similar to how React warnings work?

While I'm personally very much in favor of having this type of validation added, it wouldn't be useful in the actual form simply because we have all block definitions in block.json file now.

It makes sense to target block.json files, but isn't that just a matter of configuring ESLint to lint those files too? I'm not sure I understood this:

Do you think we could include it in the application logic instead? Maybe something enabled only in the development mode similar to how React warnings work?

Do you think we could include it in the application logic instead? Maybe something enabled only in the development mode similar to how React warnings work?

Rather than using ESLint, we could run JSON schema validation on the full block definition inside registerBlockType at runtime but only in the development env. What I meant is that it would be completely removed in production mode.

It makes sense to target block.json files, but isn't that just a matter of configuring ESLint to lint those files too?

See: https://www.npmjs.com/package/eslint-plugin-json#is-eslint-really-the-best-tool-to-lint-my-json

Is eslint really the best tool to lint my JSON?

Not really. eslint plugin interface wasn't designed to lint a completely different language but its interface is flexible enough to allow it. So this plugin is certainly unusual.

Ideally, your editor would natively supports linting JSON. If it doesn't though, then might as well use this plugin. Hacky linting is better than no linting :)

Thanks, that makes sense.

This feels very low-priority to me, and our PR count is high enough as it is, so I'm going to close it. Anyone should feel free to reopen if they want to pursue this. Thanks for the debate.